home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 266 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.1 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: vandevod@cs.rpi.edu (David Vandevoorde)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Make type_info name() distinct?
  5. Date: 3 Feb 1996 23:50:04 GMT
  6. Organization: RPI Computer Science
  7. Sender: vandevod@avs.cs.rpi.edu
  8. Approved: clamage@eng.sun.com (comp.std.c++)
  9. Message-ID: <xsorawcazry.fsf@avs.cs.rpi.edu>
  10. References: <v01530500ad36a19a2831@[194.163.74.11]>
  11.     <199602030146.RAA14333@shellx.best.com>
  12. NNTP-Posting-Host: taumet.eng.sun.com
  13. Content-Type: text
  14. X-Nntp-Posting-Host: avs.cs.rpi.edu
  15. In-Reply-To: bgibbons@best.com's message of 02 Feb 1996 17:53:46 PST
  16. X-Newsreader: Gnus v5.1
  17. Content-Length: 1287
  18. Originator: clamage@taumet
  19.  
  20.  
  21. Just some personal tastes...
  22.  
  23. >>>>> "BG" == Bill Gibbons <bgibbons@best.com> writes:
  24. [...]
  25. BG>   * How are unnamed types handled?  For example:
  26.  
  27. BG>          struct { int x; } y;
  28. BG>          typeid(y).name();
  29. BG>          (possible answers - implementation dependent
  30. BG>                              invented names based on ordinals)
  31.  
  32. How about "#none"?
  33.  
  34. BG>   * How are local types handled?  For example:
  35.  
  36. BG>          void f() { struct A { }; typeid(A).name(); }
  37. BG>          void g() { struct A { }; typeid(A).name(); }
  38.  
  39. BG>          Are these two names the same?
  40. BG>          (possible answers - yes, they are the same
  41. BG>                              implementation dependent
  42. BG>                              invented names based on function signature
  43. BG>                                but only unique for external functions)
  44.  
  45. I like: "f()::A" and "g()::A" respectively (though I haven't checked
  46. if that may lead to ambiguities or implementation difficulties).
  47.  
  48. BG> There is some chance that some canonical form will be recommended
  49. BG> in a non-normative annex in the standard.
  50.  
  51. There was a thread here some time ago concluding that RTTI would be
  52. considerably more convenient for purposes of object persistence and 
  53. transportation if this could be standardized somehow.
  54.  
  55.     Daveed
  56.  
  57. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  58.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  59.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  60. ]
  61.